Catchpoint

Catchpoint is the way to go when you need a 24/7 reliable monitoring for your servers and system anywhere around the whole world.

It is well suited if you want to monitor your service availability in China.

It also allows you to the whole request flow and you can also add RUM which is real user monitoring.

A Solid product, provides meaningful accurate data results from synthetic monitoring. Catchpoint as a vendor has acted as a reliable business partner and promotes good relationship with customers and provides them with meaningful support. Support engineer and account manager make efforts to maintain helpful relationship for services offered. Been able to work with us to provide input for code changes and enhancements for payload used for synthetics.

Catchpoint is well suited if the business demands constant health checks of their mission critical applications.

The UI is very rich and allows the user to get into as much detail as they may need to analyze a test result. If a Catchpoint node is assigned to a specific division, say divisionA, it should NOT be available for users of divisionB to schedule to run scripts or even for running instant tests. Basically, users of divisionB should only be allowed to schedule scripts on divisionB nodes as well as to run instant test only on divisionB nodes. In the main division aka client division, Catchpoint admins should be able to BOTH see the performance of the Catchpoint nodes for all divisions as well as the ability to run an instant test against any division. Currently, a Catchpoint admin can see the performance of all the Catchpoint nodes but need to switch to divisionB (say) to be able to run an instant test on a divsionB node. Users with non-admin Catchpoint roles should NOT be allowed to do this. For easier maintenance, we need the ability to copy/move scripts from divisionA to divisionB, currently we can only copy/move scripts within the same division only.

When we do a build on our system, it helps in immediately point out the areas affected by recent builds and helps us make a decision in future planning of our scope of code change, and improve the code quality of our deliverable by helping us always to be mindful of what you send in the build and it's particular impact hence narrowing down our scope of changes and help us make a better decision regarding the coding process and build process as well.

Catchpoint is very good for monitoring a static web page to ensure availability and uptime. On those static pages, the dashboards work well and give valid readouts to show our availability. We have some difficulties in a lot of our pages due to constant changes to the page, so it requires constant updating of the scripts to keep up with the changes. One of our biggest issues in keeping the tests valid.

Great for monitoring external sites.

Catchpoint is an excellent service when tracking down issues. It also has an alert system to proactively detect problems. It is difficult to massage the alerts to prevent false positives, but it does find issues if they arise. They could improve by providing better dashboards that could be displayed on a monitor and [that don't] require intervention to refresh or login regularly.

Catchpoint is very good for synthetic monitoring of URLs. By providing the ability to monitor from different points of presence (e.g. public, on-premises, etc.) you can get a good picture of how your applications are performing. The wealth of metrics captured (including the ability to define and capture custom metrics) and the awesome analytic capabilities make it well suited to getting to [the] root cause of many issues quickly. By providing the ability to monitor from public locations, it helps identify issues external to Fannie Mae.

Checking our daily availabilities through Catchpoint for the different LOBs. Less appropriate if you're looking for the specific error just once.

It is well-suited for monitoring the overall health of the application with different dashboards. Also well-suited for planned maintenance, we can easily disable the false alerts during that window and then enable them again. It's less appropriate to troubleshoot specific user sessions and doesn't provide complete error logs.